A business information enterprise system may improve an organization's ability to monitor and/or manage data in a complex business environment. For example, such a system might store a large amount of business information, such as a yearly global sales plan and profit data on both a company-wide and regional basis. Different users may then access the information in different ways. For example, a business analyst might be interested in a normalized comparison of each year's sales plan figures as compared to other years. A human resources administrator might instead want to access a list of employee names located in a particular country. In general, many different types of data could be stored by, and accessed from, a business information enterprise system (e.g., inventory data, sales data, and/or accounting data) and different types of data can often be used in different ways.
In some cases, business information is accessed through a Web-based “portal” that can display information to, and interact with, users. For example, a user might view business reports and/or select a particular item within a report to obtain further information about that item. Note that a user or group of users might want to customize the way in which information is displayed and/or interacted with via the portal.
To help a user design a personalized portal that suits his or her needs, a portal design tool may store a pre-defined set of portal elements, such as portal templates and objects. The user could then arrange and further define the portal elements as required. Note that some or all of these portal elements may be associated with business logic. For example, a sales report template might be “built into” the portal design tool such that a user will always see a particular graph when an item in a sales report is selected. Similarly, a particular type of portal element might be permitted in certain display areas (e.g., a human resources area within a portal page) while another type of portal element is not permitted in those areas.
To accommodate this type of logic, the portal design tool might include rules and other information associated with portal templates and objects. The rules might include, for example, business logic (e.g., Java instructions on how certain business parameters should be calculated) and/or a set of user interface design rules (e.g., indicating how the tool should behave when a user drags or drops items within a portal layout).
Such an approach, however, can require that a substantial amount of information be included in the portal design tool. Moreover, there may be a number of different portal design tools, and the logic and rules associated with portal elements might need to be duplicated in all of them. That is, a first portal design tool used by a first user and a second design tool used by a second user would both need to store the rules and logic associated with the business enterprise portal. In addition, when a logic rule associated with the business is changed, the change might need to be reflected for a large number of portal design tools (e.g., every design tool might need to be updated to reflect that three separate business reports have now been combined into a single report). The administrative maintenance associated with this type of approach can be both time-consuming and error-prone.
Another disadvantage of typical approaches is that a portal design tool must interact with an executing portal server while a user is designing and/or validating a portal layout. In some cases, however, a user may want to design a business portal when an executing portal server is not currently available (e.g., when he or she is “off-line” with respect to the portal server).
Approaches that may improve a users ability to design business information portals could, therefore, be desirable. Moreover, it may advantageous to provide one or more tools that facilitate a users ability to do so even when an executing portal server is not available.